Zum Hauptinhalt springen

Protokolltabelle

Call Recording schreibt zu jeder Aufzeichnung einen Protokolleintrag in eine externe SQL-Datenbank Ihrer Wahl — Metadaten beim Aufzeichnungsstart, die kryptografische Signatur nach Abschluss. Die Tabelle dient Drittsystemen als durchsuchbarer Index über alle Aufzeichnungen (Archivsysteme, DMS, Audit-Werkzeuge) und als Referenz für den Vollständigkeits- und Signaturnachweis.

Verwendung durch Dritte

Diese Schnittstelle ist für die Nutzung durch Drittsysteme freigegeben. Änderungen und Erweiterungen werden je Version in den Release Notes dokumentiert.

Grundlagen​

  • Typ: SQL-Tabelle in einer externen Datenbank. Unterstützte Systeme: MySQL, Microsoft SQL Server, PostgreSQL und Derby.
  • Konfiguration: Tab Speicherziele, Abschnitt Externes Logging — je Datenbank werden Typ, Host, Datenbankname, Benutzername, Kennwort, ein optionaler JDBC-Optionsstring sowie der Tabellenname hinterlegt. Es können mehrere Datenbanken angelegt und jeder Aufzeichnungseinstellung über die Auswahl Externes Logging eine oder mehrere davon zugeordnet werden; jede zugeordnete Datenbank erhält denselben Eintrag.
  • Tabellenerstellung: Die Tabelle muss vor dem ersten Schreibvorgang einmalig existieren. Die Schaltfläche Tabelle erstellen in der Moduloberfläche legt sie mit dem unten dokumentierten Schema an; alternativ erstellen Sie die Tabelle selbst. Tabellennamen dürfen nur Buchstaben, Ziffern und Unterstriche enthalten — andere Zeichen werden vom Modul entfernt.
  • Zugriff: Call Recording benötigt lediglich INSERT- und UPDATE-Rechte auf die Tabelle (zum Anlegen zusätzlich CREATE TABLE). Drittsysteme lesen mit eigenen Zugangsdaten direkt aus der Datenbank; das Modul stellt keinen Leseendpunkt bereit.
  • Unveränderbarkeit: Das Modul fügt Zeilen ein und ergänzt nachträglich ausschließlich die Spalte signature. Es löscht oder überschreibt keine Protokolleinträge — auch dann nicht, wenn Aufzeichnungen über die Moduloberfläche gelöscht werden. Das Protokoll bleibt damit als lückenloser Nachweis erhalten.

Spaltenschema​

SpalteTypBedeutung
basefilenameTEXTBasisname des Aufzeichnungs-Dateisatzes ohne Dateiendung, z. B. 1739948363496_004970222797821-31. Schlüssel zur Zuordnung der abgelegten Dateien.
directionTEXTGesprächsrichtung: in (eingehend) oder out (ausgehend).
timeBIGINTStartzeitpunkt der Aufzeichnung als Unix-Zeitstempel in Millisekunden (identisch mit dem Zeitstempel im Basisnamen und startTime der Ereignisse).
callidTEXTSTARFACE-Call-UUID des Anrufs (identisch mit callId im StartRecordingEvent und CallId in der Metadatendatei).
callernameTEXTAufgelöster Name des Anrufers (leer, wenn unbekannt).
callerTEXTSignalisierte Rufnummer des Anrufers.
calleeTEXTGerufene Nummer.
settingTEXTName der Aufzeichnungseinstellung, die die Aufzeichnung ausgelöst hat.
signatureTEXTBase64-kodierte RSA-Signatur (SHA256withRSA) über die Prüfsummendatei des Dateisatzes — nachgetragen nach Gesprächsende. NULL, solange keine Signatur vorliegt bzw. wenn Prüfsummensignaturen deaktiviert sind; unavailable, wenn die Signierung fehlgeschlagen ist.

Das von Tabelle erstellen erzeugte Schema (Typenbezeichnungen je nach Datenbanksystem):

CREATE TABLE callrecording_log (
  basefilename TEXT,
  direction    TEXT,
  time         BIGINT,
  callid       TEXT,
  callername   TEXT,
  caller       TEXT,
  callee       TEXT,
  setting      TEXT,
  signature    TEXT
);

Die Tabelle wird ohne Primärschlüssel und Indizes angelegt. Für größere Bestände empfiehlt sich ein eigener Index, etwa auf time und callid — das Modul greift beim Schreiben nur über basefilename zu und wird davon nicht beeinträchtigt.

Schreibzeitpunkte​

ZeitpunktOperationInhalt
AufzeichnungsstartINSERTAlle Metadatenspalten (basefilename … setting); signature bleibt NULL. Der Eintrag entsteht in dem Moment, in dem der Mitschnitt beginnt — noch während des Gesprächs.
Nach GesprächsendeUPDATE der Spalte signature (Filter: basefilename)Base64-Signatur der Prüfsummendatei. Erfolgt im 30-Sekunden-Takt der Nachverarbeitung, sobald die Aufzeichnungsdateien abgeschlossen und signiert sind — typischerweise unter einer Minute nach dem Auflegen.

Das UPDATE erfolgt nur, wenn in der Aufzeichnungseinstellung „Prüfsummensignaturen aktivieren" gesetzt ist und kein temporärer Speicher verwendet wird; andernfalls bleibt signature dauerhaft NULL. Schlägt die Signaturerstellung fehl (z. B. beschädigter Schlüsselspeicher), trägt das Modul den Festwert unavailable ein.

Beispielabfragen​

Aufzeichnungen eines Tages (04.08.2026, UTC)
SELECT basefilename, direction, callid, callername, caller, callee, setting
FROM callrecording_log
WHERE time >= 1785801600000
  AND time <  1785888000000
ORDER BY time;

Der Zeitstempel lässt sich datenbankseitig umrechnen — MySQL: FROM_UNIXTIME(time / 1000), PostgreSQL: to_timestamp(time / 1000.0), SQL Server: DATEADD(SECOND, time / 1000, '1970-01-01').

Protokolleintrag zu einer STARFACE-Call-UUID
SELECT *
FROM callrecording_log
WHERE callid = '5e8f0f5a-1d24-4f6b-9c3a-7b2f9d4e8a11';
Signaturkontrolle: abgeschlossene Aufzeichnungen ohne Signatur
SELECT basefilename, direction, time, callid
FROM callrecording_log
WHERE signature IS NULL
  AND time < 1785801600000   -- älter als der geprüfte Stichtag
ORDER BY time;
Mengengerüst je Richtung und Aufzeichnungseinstellung
SELECT setting, direction, COUNT(*) AS anzahl
FROM callrecording_log
GROUP BY setting, direction
ORDER BY setting, direction;
Anwendungsbeispiel

Ein Archivsystem gleicht nächtlich die Protokolltabelle mit dem Speicherziel ab: Für jede Zeile muss ein Dateisatz basefilename.* existieren, dessen Signaturdatei dem Wert in signature entspricht. Fehlende Dateien oder abweichende Signaturen werden als Compliance-Vorfall gemeldet — die Vollständigkeit des Archivs ist damit täglich belegt.

Fehler-/Sonderfälle​

SituationVerhalten
Zieldatenbank beim Aufzeichnungsstart nicht erreichbarDer INSERT wird nicht wiederholt — der Eintrag fehlt dauerhaft (Fehler im Modul-Log). Die Aufzeichnung selbst ist davon nicht betroffen.
Zieldatenbank beim Signatur-Update nicht erreichbarDas UPDATE wird nicht wiederholt; signature bleibt NULL, obwohl die Signaturdatei im Speicherziel existiert.
Unvollständige DatenbankkonfigurationEs wird nicht geschrieben (Hinweis im Modul-Log).
Tabelle existiert nichtSchreibvorgänge schlagen fehl; die Tabelle muss einmalig über Tabelle erstellen oder manuell angelegt werden. Tabelle erstellen schlägt fehl, wenn bereits eine gleichnamige Tabelle existiert.
Aufzeichnungseinstellung mit temporärem SpeicherDer INSERT erfolgt regulär; ein Signatur-Update findet nicht statt (signature bleibt NULL).
Löschung von AufzeichnungenProtokollzeilen bleiben bestehen — das Modul führt keine DELETE-Operationen aus.

Versionierung & Kompatibilität​

Spaltennamen und -bedeutung sind stabile Verträge; Erweiterungen erfolgen additiv (neue Spalten). Bauen Sie Abfragen daher auf benannte Spalten statt SELECT * auf, wenn Sie auf Positionsstabilität angewiesen sind. Änderungen am Schema oder an den Schreibzeitpunkten dokumentieren die Release Notes der jeweiligen Modulversion.

Inhaltsverzeichnis